今日目標

• 理解為什麼「Container 狀態顯示 Running」不代表應用程式真的能正常工作。
• 搞懂 Kubernetes 三大健康檢查探針：Startup Probe、Liveness Probe 與 Readiness Probe 的職責分工與觸發時機。
• 掌握三種常見探測方式：httpGet、exec 與 tcpSocket。
• 實戰操作：配置探針模擬應用卡死自癒重啟，以及初始化未完成時拒絕接入流量的場景。

痛點場景：容器沒死，但服務已經癱瘓了？

在前面的章節中，Kubernetes 主要是透過監控容器的 進程（Process） 是否存活來判斷容器是否健康。但很多時候，系統會遇到以下「假活」的情況：

1. 程式死鎖或記憶體洩漏（Deadlock / Hang）：主進程（Process ID 1）依然在運行，但後端執行緒全部卡死，無法回應任何 HTTP 請求。
2. 暖機尚未完成（Slow Startup）：Spring Boot 或大型 Java 服務需要 60 秒載入 Context 與建立資料庫連線池，但在前 50 秒若有使用者流量進來，會直接收到 502 / 500 錯誤。
3. 外部相依元件斷線：資料庫或 Redis 暫時斷線，應用程式暫時無法處理請求，需要暫停接客，但並不適合立刻把容器殺死重啟。

為了讓 Kubernetes 能「真正理解」應用程式內部的健康狀況，我們需要使用 Probes（健康檢查探針）。

三大探針的職責分工

Kubernetes 提供了三種不同階段與目的的探針：

三種常見的探測方式

Kubernetes 支援以下三種探測機制：

1. httpGet：向容器指定 Port 和 Path 發送 HTTP GET 請求（回傳 HTTP 200–399 視為成功，其餘視為失敗）。
2. exec：在容器內部執行指定的 Shell 指令（Exit Code 為 0 視為成功）。
3. tcpSocket：嘗試與容器指定 Port 建立 TCP 連線（連線成功即視為健康）。

實戰演練 A：Liveness Probe 實測自癒重啟

我們建立一個模擬應用：開機前 15 秒建立 /tmp/healthy 檔案，15 秒後刪除該檔案模擬程式崩潰。

步驟 1：建立 liveness-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
spec:
  containers:
    - name: liveness
      image: busybox
      args:
        - /bin/sh
        - -c
        - touch /tmp/healthy; sleep 15; rm -rf /tmp/healthy; sleep 600
      livenessProbe:
        exec:
          command:
            - cat
            - /tmp/healthy
        initialDelaySeconds: 5 # 容器啟動後 5 秒開始第一次檢查
        periodSeconds: 5       # 每隔 5 秒檢查一次
        failureThreshold: 2    # 連續失敗 2 次即判定為不健康

步驟 2：套用配置並觀察自癒過程

kubectl apply -f liveness-demo.yaml

# 持續觀察 Pod 狀態與重啟次數 (RESTARTS)
kubectl get pods liveness-exec-pod -w

你會發現：

• 前 15 秒，Pod 處於 Running，RESTARTS 為 0。
• 15 秒後檔案被刪除，探針檢查失敗。
• 約 25 秒時，K8s 判定容器死亡，自動將容器重啟（RESTARTS 變成 1）！

實戰演練 B：Readiness Probe 流量平滑接入

建立一個標準的 HTTP 探針範例，只有當 /healthz 端點回傳 200 時，Service 才會將流量導向該 Pod。

步驟 1：建立 readiness-demo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: readiness-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web
          image: nginx:1.25
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10 # 模擬前 10 秒在暖機
            periodSeconds: 3

套用配置：

kubectl apply -f readiness-demo.yaml

觀察 Pod 狀態：

kubectl get pods -l app=web-app

在前 10 秒內，你會看到 READY 欄位顯示 0/1，雖然容器已經在執行，但此時任何外部流量都不會被送進來。直到 10 秒後探針通過，READY 才會變成 1/1，開始正式接客！

關鍵參數解析

• initialDelaySeconds：容器啟動後延遲幾秒才開始執行探針（避免太早檢查導致誤殺）。
• periodSeconds：檢查間隔頻率（預設 10 秒）。
• timeoutSeconds：每次檢查等待回應的超時時間（預設 1 秒）。
• successThreshold：探針失敗後，需連續成功幾次才算恢復健康（預設 1 次）。
• failureThreshold：需連續失敗幾次才正式觸發重啟或踢除動作（預設 3 次）。

本日小結

今天我們搞懂了容器維運中最重要的「體檢制度」：

• Startup Probe：保護慢速啟動的應用不被誤殺。
• Liveness Probe：及時殺死死鎖或癱瘓的容器，達成真正的自動自癒。
• Readiness Probe：嚴格控管流量入口，確保只有百分之百準備好的 Pod 才能服務使用者。

當我們的系統具備了自我修復能力後，如果突然迎來雙 11 或促銷活動帶來的數倍流量，我們該如何讓 Kubernetes 自動根據 CPU 負載加開 Pod 副本？

明天 Day 23，我們將學習自動彈性伸縮的神技：「自動彈性伸縮：Horizontal Pod Autoscaler (HPA) 實戰」！